Applications of all types often rely on communication with other applications to perform their job. The communication includes requests by one application for functions and services from another, and can occur within a system or between different and/or remote systems. One example of a system is R/3a set of integrated business applications from SAP AG of Walldorf, Germany. R/3 uses the client/server model and provides the ability to store, retrieve, analyze, and process business data for financial analysis, production operation, human resource management, and other business processes.
Whether communication is conducted within one system or among different systems, an interface protocol is needed to manage each communication. One type of such interface is called a remote function call (RFC). The term RFC also refers to an SAP interface protocol based on CPI-C that is used to simplify the programming of communication processes between applications. For example, RFCs are used by an R/3 application to call other applications and instigate them to perform a particular task. As used herein, the term RFC relates generally to a communication interface protocol to manage data transfer between a source system and a target system. RFCs also manage the communication process, parameter transfer and error handling between a sending application and a receiving application. For different operating systems, an RFC library is available as an application programming interface (API).
An early version of an RFC, called synchronous RFC (sRFC), required both participating applications to communicate synchronously, which limited their use. Subsequent generations of RFC have provided a considerably extended range of functions, such as, for example, serialization, which guarantees that processing occurs once, and the target system does not have to be available. The range of functions was further extended by introduction of a queued RFC (qRFC) that uses outbound and/or inbound queues to collect RFC data to guarantee processing occurs exactly once and in a particular order. The qRFC enables parallelization of application tasks.
A function module is a modular component of a computer software program. The RFC is the communication protocol used to serialize the call at the sender, to transfer the call, and deserialize the call at the receiver. The qRFCs enable alignment or parallelization of calls at the sender, i.e. the originator/caller. The aligned calls are also known as an LUW, or simply “unit of work.” The transactional RFC protocol guarantees that the calls of one LUW are transferred indivisibly, and the qRFCs additionally guarantee that the sequence for transfer is the same as at calling time.
The function modules are a special class of application program subroutines, and form the basis of a componentized application system. In the calling interface of a function module, import, changing, export and table parameters are defined. A changed parameter value is assessed after execution of the function and the results returned. The syntax for calling function modules is shown in FIG. 1. Function modules allow for the reuse of routines, and include a clearly defined calling interface, while the data objects of the calling application and of the functional module are located in separate work areas. Function modules can be called across system boundaries via RFC, and thus serve as the basis for distributed business applications.
Consider FIG. 2, in which a sending (or calling) application 104 (or client) in a source system 102 uses a first RFC connection 106 to communicate with a receiving (or target) application 114 (or server) in a target system 112. If the data being sent is not interrelated, a particular kind of RFC, a transactional RFC (tRFC), is used to transfer data. Using a tRFC, each function module sent to the target system 112 is guaranteed to be processed once. The order in which the function modules are executed, and the time they are executed, cannot be determined. If a transfer error occurs, a batch job is scheduled in the sending application 104 that resends the function module after a period of time.
If the data being sent is interrelated, and the function modules need to be executed exactly once in order (EOIO), an outbound queue 108 is provided in the source system 102, and may be used with an inbound queue 118 in the target system 112. The outbound queue 108 in the client system is needed to guarantee the sequence of processing, and to prevent individual applications from blocking all work processes in the source system 102. These queues require yet another particular type of RFC, the queued RFC (qRFC). Communication with a qRFC with inbound queue 118 and/or outbound queue 108 involves a three- or two -step processing and transfer model respectively. Each step is independent to ensure that asynchronous processing is as secure as possible. In the first step, business data from the sending application 104 is written to the outbound queue 108. After the business data is stored, in the second step a QOUT scheduler 110 transfers the business data from the source system 102 to the target system 112.
In the two-step process, used for communication between heterogeneous systems, the QOUT scheduler 110 reads the stored business data from the outbound queue 108 and performs the calculations. In this scenario, the source system 102 uses the outbound queue 108 to serialize the data being sent, such that dependent function modules (for example, “update” followed by “change”) are placed in the outbound queue of the source system 102 and are guaranteed to be sent in the correct sequence, and only once, to the target system 112.
If the target system 112 is of a type that includes the inbound queue 118, the business data is transferred to the inbound queue 118. In the third step, a QIN scheduler 120 in the target system 112 activates processing of the business data in the inbound queue 118 in the target system 112. The QIN scheduler 120 is a local instance of a master scheduler (not shown). In this scenario, the QIN scheduler 120 reads all the business data, and calculates dependencies, i.e. shared resources of functions and/or services, between the sending application 104 and the receiving application 114 based on the business data. This guarantees that the sequence is preserved, and at the same time controls the resources in the source system 102 and in the target system 112. For example, the inbound queue 118 only processes as many function modules as the current resources in the target system 112 will allow, hence preventing a server being blocked by a client.
However, the dependencies between sender system and receiver system increasingly overwhelm one or both system's processing resources during runtime. Execution of a function or service is slowed when the scheduler must determine information about required resources for the function or service, and whether those resources are currently available. Further, load balancing of qRFCs is done based on logon groups, which had heretofore been a fairly accurate method of balancing work among schedulers. However, a dramatic increase in inter-application communication of client/server business applications has made logon-based load balancing ineffective.
The transactional behavior of the qRFC does not allow fundamental savings at the processing side of an individual unit, but the application of more or faster hardware is now directly perceivable with more throughput. The limiting factors of the qRFC are the performance of the database and the processing speed of the units. Further, the current qRFC protocol is limited in its resource allocation and management, i.e., calling applications can sometimes flood the system with calls.